When transmitting data from a server to a computer system, or from a computer system to another computer system, it is not guaranteed that 100% of the data requested by the user will arrive. Often times some of the data is lost in the transmission or is never sent at all.
Accordingly, methods have been provided for verifying proper receipt of data and when, for instance, a packet in a packetized data stream is not received, for requesting retransmission. In these methods, a data verification layer in a communication protocol stack tracks the received packets and requests retransmission if a packet does not arrive as expected.
As recognized herein, current standards for tracking data often contain overhead and latency which is too high for certain data streaming environments, such as telephony. Nonetheless, a receiver must buffer data before sending it on to higher levels in the protocol stack while waiting for a retransmitted packet. Likewise, after sending data a transmitter must buffer it for a period after transmission, in case the receiver requests retransmission. The length of the transmitter buffer (sometimes referred to as a discard period) in current systems is predefined in an attempt to balance the need to wait long enough for a dropped packet to be requested and retransmitted, but to also avoid having to accumulate more packets post-transmission than is necessary. In terms of the transmitter buffer, a buffer length that is too long requires more memory than is necessary, while a buffer length that is too short means that the retransmission mechanism will not function. The present system is presented in response to the above critical observations.